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From the business and international catastrophes of the past two 
years, a new information technology initiative has arisen. It is called 
customer relationship management (CRM) and it is dedicated to 
improving through automated, especially Internet-driven, means the 
entire arena of customer service and interaction. If the amount of 
print space, conference literature and position advertisements 
devoted to a topic is a criterion for importance, CRM is a hot button 
for the IT industry as well as the entire business world. In reality, 
customer-driven applications have been in existence for years. 
Successful sales and marketing organizations have always used the 
principles which CRM now formalizes. So it is important that the CRM 
starts with an organization vision and mission, which should become 
part of the mind-set of employees. The objective of CRM is to give 
customers satisfactory and pleasant experiences in doing business 
with an organization. Such experiences will result in more profitable 
business. CRM technology enables the organization to apply sound 
relationship development and maintenance principles on a larger 
scale within the organization. In the application of CRM technology, 
techniques used by successful sales and marketing people become 
available to all employees. However, the employees must be trained 
and incentivised to take advantage of this powerful tool. 


The advent of the Internet, personal computers, sophisticated 
database management systems capable of handling very large 
volumes of data efficiently, hand-held technologies, GUI-based 
workstations, data distribution and access facilities have made the 
CRM concept workable and have significantly raised management's 
expectations. 


Enabling technologies and the thrust toward a customer-centric 
business focus have brought CRM applications to the forefront as a 
viable approach for increased competitiveness and_ profitability. 
Unfortunately, the success rate in realizing potential benefits from 
CRM projects is still lower than expected and, in fact, many projects 
fail even before a first phase is completed. 


In the rush to implement a CRM application, many potential problems 
and pitfalls are being overlooked. Some involve the same 
considerations and principles that have been important for years, but 
many of these have a new twist. This article walks through a number 


of major potential problem areas and their impact on the success of a 
CRM project. For each problem, solutions are suggested. 


Several broad categories of problems exist: conceptual, managerial 
and technical. However, the most important underlying theme of 
these problems is that they involve everyone, from senior business 
executives, sales and marketing management, customer 
representatives to IT technical personnel. The best way to solve 
problems is, of course, to anticipate them pro-actively and not let 
them become problems. 


Problem #1 - Many Misunderstandings about CRM Exist 


The most significant problem is the perception that CRM is a magic 
bullet, a panacea for all customer support problems. This is simply not 
true. This perception and the expectations that follow from it are 
potentially catastrophic. Overselling something as "new and hot" as 
CRM is likely to occur and have serious consequences for the next 
new and hot project. Any future CRM effort could be seriously 
compromised, not to mention the reputation of the IS department. 
This, in turn, will continue to deprive the organization of the benefits 
that should accrue from CRM 


Another conceptual pitfall is management does not understand the 
consequences of not having access to integrated, cleansed and 
consistent data, which is the technical goal. The issue of stewardship 
vs. ownership will surface very quickly, opening up potential political 
issues that have long been dormant or which have been avoided by 
costly manual compilation of data. 


Because CRM provides answers to queries of internal as well as 
external customers, the entire process of creating CRM is subject to 
misunderstanding. The CRM application is an enabler, not a 
substitute for human relationship. Failure to distinguish between the 
availability of value- added data and the users’ ability to use the data 
for better customer service cause an expectation gap. 


In addition, the amount of time required to be spent with management 
and users who understand real customer relationship needs is almost 
always underestimated. Some tasks, such as vision development, 
analysis and requirements definition for CRM, should be carried out 
differently than with traditional IT system development. 


Solution #1 


The best solution to heading off problems is systematic education and 
communication with all levels of the organization, especially the 
executive sponsor, the project team, key users and data stewards. The 
education must clearly communicate that in CRM, technology 
contributes only 20 percent of the total effort. Having the quality data 
is another 20 percent. The rest is requirement analysis, system 
design, training the users and assuring that this application does, in 
fact, improve customer relationships. 


The CRM project team must consist of successful salespeople, 
customer reps, knowledgeable users, data analysts and the CRM 
package expert. The team must be aware of what can and can’t be 
done with CRM, and what its problems are. 


Management must be appropriately educated on what to expect and 
not to expect. They must be made aware of their commitment. Time 
spent in education is never wasted. 


Problem #2 - The Scope of the CRM Project is Inappropriate 


While the proper choice of scope is critical to all projects, doubtless 
dating from the very earliest systems, the correct CRM focus should 
be based on customer expectations, which could vary with the 
customer segments in your industry. For example, the needs of a 
retail customer are significantly different than a wholesale or 
institutional customer. If you combine both segments in one project 
phase and try to fit in one straightjacket, you could have serious 
problems. 


In the case of one state government, the scope of a major CRM project 
included all member departments. The definition of information 
delivery and data architecture to enable CRM simply proved to be too 
much for the group. This, coupled with the lack of strong executive 
management , caused the project to fail. 


In addition, if the definition of scope is too large, the analysis and 
implementation becomes complex, takes too long and people lose 
interest. 


Solution #2 


A sound solution to the scope issue is based on the understanding that 
the organization is on a learning curve in applying CRM. Try starting 
small, following the KISS (keep it simple, silly) rule. This is an old but 
successful approach technique to dealing with new things. The scope 
for CRM implementation could be one customer segment where users 


are receptive, knowledgeable and are available to work with you, and 
quality data is easily available. Any area you select must in any case 
have a committed executive sponsor. 


The use of time-boxing techniques can also help control the project 
scope. For instance, limit the analysis to no more than four weeks and 
design and implementation to four weeks. Allow adequate time for 
piloting and field testing which should be another four weeks. This 
will leave adequate time for attending to infrastructure requirements 
and can still provide a usable facility as soon as practicable. It will 
also reinforce the value of the starting-small approach. 


Problem #3 - The CRM Project has No Committed Executive Sponsor 


The most serious - and usually fatal - problem is lack of an executive 
sponsor with an absolutely burning desire to see the project through. 
Without the blessing of strong sponsorship, any project can fail. A 
conflict in scope may develop, the right resources may not be 
available and user participation may be inadequate. However, some of 
the subtle pitfalls in dealing with data that must be consistent across 
enterprise components can also cause unanticipated difficulties. It is 
quite common, for instance, for groups, even small ones, to be unable 
to agree on common definitions of data and delivery mechanisms. 
Moreover, when the attempt is made to define requirements for 
several disparate customer segments together, this phenomenon can 
become more pronounced. As companies move to a greater degree of 
customer focus, these types of problems will surface with increasing 
frequency and severity. 


Last, but not the least, is the need for data quality. At times the effort 
and commitment required to assure adequate data quality for CRM is 
much more than anticipated. The effect of not having the right 
executive sponsor to make the appropriate commitment can cause a 
project to bog down beyond help. 


Solution #3 


The solution to this problem is clear and obvious; the sponsor of the 
project must be an executive with sufficient clout as well as having a 
need for CRM. This person should have a track record sufficient to 
devote the adequate resources to the project. In addition, he or she 
should have the authority to make final decisions on the myriad issues 
of data definition, delivery mechanism and quality metrics that will 
inevitably arise in a CRM project. 


In one chemical company, for instance, the inability of groups to agree 
on a common definition of terms such as "head count" and "net sales" 
caused an impasse. The issue was resolved promptly and decisively by 
the controller, keeping the project on schedule. Sponsorship by an 
executive with a burning desire and with budgets, stature and the 
ability to make prompt and final decisions will see a project through 
to success in most cases. 


Problem #4 - The CRM Project Team May Lack Skills and Experience 


Foremost among technical problems is lack of skills and experience in 
all stages of the CRM project. The application of traditional 
techniques in definition of requirements, for instance, will not work. 
Using a structured approach with its reliance on data and process 
models will lead only up a blind alley, since modern CRM techniques 
are concerned with answering customer questions, solving customer 
problems and giving customers pleasant experiences in doing 
business with your organization. Analysis to define these needs, aside 
from standard reports and customer communications, may be a highly 
iterative process, continuing even after the CRM system is populated 
with data. Not knowing this in advance may cause serious 
underestimation of project costs and time to complete. 


Traditional modeling techniques will not be able to determine how 
many different ways data may be summarized or sorted. Not 
understanding the level of detail required by queries can also cause 
having either too much detailed data, or too little. Another 
shortcoming of traditional modeling techniques is that they do not 
address well data that may be highly summarized or derived. Not 
understanding this may result in data structures that are inadequate. 


Many technical people with data modeling or database experience 
may think they know how to design for CRM. But without firsthand 
experience some of the problems unique to CRM analysis and design, 
the project timeline will run longer than planned. At worst it could 
end up as a major failure. Either way it could easily disappoint 
executive sponsors and other clientele, running the risk of 
jeopardizing future CRM efforts. 


Solution #4 


The most effective solution is to have an experienced high-level 
individual who can lead, staff, educate and who is available 
throughout the initial project from start to finish. This will not only 
insure project success but will also instill in the organization the 
necessary level of confidence to continue with expansion of CRM. 


Having experience in using a particular set of tools is necessary but 
not sufficient. More critical is having experience in implementing a 
successful CRM environment with satisfied customers. 


In addition, specialized training in the form of in-house workshops for 
the project team will pay off both in the short and long run. Initially 
the team’s learning curve will be reduced and many wrong turns 
prevented. And for the long term, the entire organization will benefit 
sooner from the increased credibility that a first success will bring. 


The following steps are recommended for planning and analysis in 
order to plan the system implementation. 


Planning 


The team must consist of users as well as business area experts. A 
steering committee comprised of senior executives including the 
Sponsor is necessary to communicate the vision, set a direction and 
make crucial decisions on desired quality metrics. The time line, as a 
general rule, should not be more than for four months (at the most six 
months) for first phase. 


Requirement Analysis 


«e Define market/customer segmentation. The analysis should treat 
each segment separately if necessary. 

e Set short-term and long-term goals along with the metrics to be 
used. 

e Identify key stakeholders internal as well as external. 

e Define the interaction (touch) points with the customer for the 
whole life cycle of the customer interaction. 

«e For each segment, define customer expectations for the quality 
service. 

«e For each segment, define the expectations of the internal user. 

«e For each segment, define decisions to be made, problems to be 
solved, questions to be answered and reports to be made. 

e Define the trend and promotional analysis needs. 

e Define data needs with timeliness, summarization, historical 
period and naming and formatting for the users. 

e Identify the sources of data. 

e Define data quality and the cleansing required. 

¢ Define privacy/security constraints. 


Prototyping 


If you are making drastic changes in the current environment, you 
should prototype deliverables for the user’s understanding and proof 
of concept. 


Once the system developed or tailored you should pilot it with a small 
subset of the users. At this time you would develop manuals and 
training material for users. 


Problem #5 - Risks Inherent in Using New Technology May Increase 


The risk of using new technology, like other problems outlined in this 
article, is always a critical factor in IS projects. However, in the case 
of CRM, which is conceptually different and may have a large user 
base, the usual risks of pioneering are increased. Most of the 
salespeople have their own way of managing their relationships and 
oftentimes resist the discipline as well as constraints of an automated 
system. The technology can be new both to the parent organization 
and to its users as well. Coupled with a lack of organizational 
experience, the results can be devastating and expensive. Mixing 
vendors, especially in the emerging Internet market, could also be 
catastrophic. 


Some CRM technology is, and probably will be for some time, in a 
state of flux. Since most of the CRM users are less proficient in 
computer skills, the bells and whistles so attractive to IT professionals 
in new technology could be at best underutilized and at worst wasted. 
In addition, the presence of bugs, which are known to crop up in new 
technology, could turn users off very easily following on the heels of a 
lengthy gestation period for CRM. Remember, as with all new things, 
idiosyncrasies in new technology may surface at inopportune 
moments, since Murphy’s Law has not yet been repealed for CRM. 


Another aspect of the risk in employing new technology is not 
knowing what additional requirements or restrictions it may impose. 
If it is necessary to acquire and learn new technology, the time and 
effort required can detract from the most important part of the CRM 
effort, analysis and requirements definition. A result of this may be a 
misallocation of project resources and the attendant loss of time as 
well as a depletion of customer and management resources. 


Solution #5 


Wherever possible use existing, tried- and-proven technology, 
preferably that with which the organization has some experience. If 
tool interfaces are needed, it may not be worth the trouble to create 
them. Vendors are very sensitive to what is saleable, and it is 


predictable that technology capable of performing needed functions 
will be plentifully available in the future. 


For management and lesser-skilled customers, you must select 
technology which is simple, sturdy, bug-free and well proven in the 
field. The tools selected must be made easy to learn and easy to use if 
they are not that way to start with. 


If the need to use new technology persists, it would be best to create 
a small pilot project. In this way some organizational learning will 
take place, and success is better assured. In such cases it is highly 
recommended to bring in outside expertise, which will be available for 
at least a pilot project. Although this appears more costly in the short 
run, the results will include a finished project and increased 
confidence in the technology employed. It will also allow proper 
allocation of resources so that existing personnel can capitalize on 
their current knowledge while learning a new tool. 


Problem #6 - Excessive Reliance on Tools 


Excessive reliance on tools - any tools - is caused by technophiles 
usually within the IT department. Somehow, an expectation that tools 
are magic is never far from peoples’ minds, especially those of 
technical professionals. This is not to say that tools are not needed. 
Developing CRM does require some functions on a large scale. For 
instance, the back-end integration of data, cleansing or scrubbing 
data, bulk movement of data as well as user-friendly GUI interfaces 
for data delivery are demanding technical issues even with the best 
tools. 


Unfortunately the level of integration among products of various 
vendors is still not high. The result is that the project team could 
become fixated on the tools issues and, as a result, get nothing done 
while waiting for the right tool or use up valuable resources in making 
the tool work. The team may also try to collect data and do everything 
the tool demands without even understanding why. This could lead to 
imposing a tool's limitations on the CRM solution. 


Solution #6 


Put the entire tool issue in perspective by not building the CRM 
project around tools. Establish a sound methodology and tailor it to 
the scope and deliverables of the project. Let the methodology guide 
the use of the tool, not the other way around 


Then, either look for appropriate tools or use tools available within 
the organization that are known, well proven and serviceable. 
Capitalize on the strength of the tool and work around its weaknesses. 
Remember that the most important activities are the up-front analysis 
tasks, which may not require the most sophisticated tools. These tasks 
involve understanding customer needs, defining data architecture, 
educating users and obtaining their buy-in. If necessary, build extra 
time into the project schedule to allow for the use of "archaic" tools. 


Remember: "A fool with a tool is still a fool." 


Problem #7 - The CRM Team May Underestimate the Need for Data 
Quality 


Underestimation of the complexities in integrating CRM data from 
disparate sources is very common. More challenging is the quality 
issue. Most of the legacy systems suffer from poor quality and when 
you try to integrate them across systems and databases, the problem 
is compounded severely. A majority of business intelligence and CRM 
projects that have failed did so because of the lack of data quality and 
inability to improve it. 


If current systems, which may feed the CRM project, are not 
documented properly, or if a lack of expertise exists in extracting data 
from these operational systems, the difficulties of transformation and 
scrubbing data may be grossly underestimated. Oftentimes, customer 
and product codes used within different systems may not be common 
or compatible. 


In addition, extracting, transforming and scrubbing data from 
proprietary software can be a time bomb. Not fully understanding the 
architecture of an accounting package, for instance, can easily cause 
a delay. Proprietary packages may also cause other unforeseen 
problems. One small CRM project, for instance, was bogged down for 
months simply for lack of a data extraction facility from a simple 
package with a proprietary architecture. 


A more subtle type of problem is identifying data that is required by 
the CRM project but does not currently exist in any automated or 
legacy data source within the organization. Such data must be 
acquired from the outside and may be very difficult or expensive to 
find. 


Solution #7 


Detailed knowledge of the systems feeding the CRM project is 
essential to avoiding undesired effects in loading data. If adequate 
systems documentation does not exist, then allow extra time during 
the analysis phase to create documentation. In addition, it is 
important also to analyze the data very carefully to anticipate the 
nature and level of scrubbing that will be necessary. A simple case 
involves date formats. The CRM project must present dates that are 
consistent even if the dates come from different sources. If your 
organization has not standardized on a single date format for all 
systems, you must take this into account in planning the project and 
designing the extraction process. 


The solution to potential problems raised by proprietary software is 
simply to know its architecture and limitations. If documentation or 
in-house knowledge is not sufficient, it will be necessary to work with 
the vendor to determine whether data may be extracted, exactly how 
it appears when extracted and what is necessary to perform 
extraction. This will avoid unpleasant surprises and additional work 
during the design and implementation of scrubbing, transforming and 
loading procedures. 


These activities should be part of up-front planning when considering 
a CRM project. Indeed, if you are considering purchasing a package 
and at the same time implementing CRM, it is imperative that these 
questions be answered during package evaluation and selection. It is 
essential, for instance, to assess the degree of compatibility involved 
in the data interface between the legacy systems and the CRM 
project. The cost of building and maintaining such an interface should 
be included in package evaluation criteria. 


The issue of dealing with business changes lies at the heart of systems 
maintenance. The CRM project too must be maintained, but the 
question is more critical, since the data is historical. During analysis 
and requirements definition, it is very important to ascertain how 
sensitive each type of data may be to business changes, and what 
acceptable limits are for responses to queries for changed data. At 
this point, it may be necessary to communicate to management some 
of the limitations in dealing with historical data and possible costs 
that would be incurred in a conversion mechanism. 


In the case of data that is required but does not exist, it is first 
necessary to ascertain that this is the case, which, again, will be done 
by careful analysis of the sources of data required by CRM users. At 
that point, it may be necessary to design a mechanism or possibly 
even a system to introduce that data into the CRM project at the 
appropriate time and in the appropriate format. For instance, if your 


organization purchases competitive sales data from external sources 
but desires to compare this data with your sales districts, it will be 
necessary to create a mechanism, perhaps using ZIP codes, that does 
the necessary mapping and integrates the two kinds of data. Or, it 
may be quite possible to pay your source vendors for this service and 
simply transmit data to them via a simple spreadsheet. 


Problem #8 - The CRM Project May be Implemented in One Big Step 


If a sound project methodology, especially involving phasing, is not 
followed, many of the problems noted elsewhere in this article would 
be magnified out of proportion. For instance, the size and physical 
design of a CRM database, which are major factors in performance, 
cannot possibly be known until the types of queries have been 
thoroughly defined and the level of summarization determined. Lack 
of experience in integrating different kinds of data could also cause 
dislocations in a project schedule. 


Solution #8 


Many of the management issues - and technical problems as well - 
can be addressed and minimized by phasing the project based on the 
type of data required. 


Manageable phases in a typical CRM project are outlined below. You 
can pick, choose or combine, according to your needs and 
management priority. 


1. Bring into the CRM project relatively stable, less- volatile customer 
master data for all customer entities. 


2. Load more volatile data, but that which is easily scrubbed or 
requires less effort to define and create consistency (e.g., financial, 
sales) 


3. Populate with data that is more problematic or less clearly defined, 
that may require significant scrubbing and transformation (e.g., 
planning, forecasting) 


4. Implement with data that does not exist in legacy systems, and may 
need to be created in order to respond to CRM needs (e.g., customer 
demographics). 


5. Incorporate externally supplied data, for instance news services 
from commercial sources, such as business partners. 


It will not always be easy to proceed in this manner. However, 
recognition that some kinds of data will be easier to work with than 
others can serve as a guide in planning the project. In this way the 
risk is minimized during the initial stages and credibility is 
established. In addition, adequate time can be allocated for dealing 
with more difficult or problematic data at a later stages once a basic 
system is implemented and in use. 


Problem #9 - The CRM Project Team May Neglect Security Issues 


Finally, you must remember that the CRM project is an open facility - 
normally a Web-based system - that will store and deliver customer- 
sensitive data potentially open to many employees and customers. 
What is your exposure in storing this kind of data in the CRM project? 
Is the CRM project accessible via a public or private network? As the 
CRM project grows and becomes more visible and important as a 
corporate asset, this concern could grow. Standard security controls 
or tools, particularly in a distributed environment, may not provide 
sufficient protection without precautions. In an operational system, 
security to the user may be affected via a transaction code or at the 
terminal or workstation level. However, in the CRM project, data in 
one column of a table not only can have a different source from the 
next column, it can also have a different security requirement. 
Customer’s personal, medical, family and income oriented data calls 
for the highest level of privacy. One major global pharmaceutical firm 
released to Internet public their customers’ private data by one wrong 
stroke of key. You can imagine the damage caused by one error by 
one employee. 


Solution #9 


Do not omit security from planning and implementation 
considerations. If necessary use a security specialist and try to use 
tools that provide column and value-level security. If a public network 
of any kind is used, consider encryption. In addition, a special 
program of security education will pay dividends. In the age of 
globalization and the magic of the Internet, it is too easy for users to 
forget that an open facility has another side to it, and a few extra 
reminders on security issues and procedures will minimize the risk of 
data going to unintended and unauthorized destinations. The security 
should be implemented both within as well as without the automated 
system. Employees must be trained in the over all security system. 


Problem #10 - The CRM Project May Lack Ongoing Post- 
Implementation Follow-Up 


To be of best use CRM must respond to continually changing 
customer service. Lack of a mechanism for addressing changes will 
rapidly cause the CRM project to stagnate and lose its utility. 


Just because the CRM project exists does not mean everyone will rush 
to use it, despite advance publicity and a strong sponsor. This will 
undercut the ultimate potential of the CRM project as a profitability 
tool. 


The customer user base too is potentially problematic. We are dealing 
with at best a mixed bag of query formulation skills, possibly general 
computer skills, which could make individuals a bit shy in taking 
maximum advantage of the CRM project opportunities. Your 
salespeople may be on road most of the time. In addition, problems 
will always crop up with a new facility, and users, particularly high- 
ranking customer users, can easily become impatient in dealing with 
them. Some of them will make their unhappiness known, but others 
may simply not communicate the issues, and they will silently stop 
using the facility. This could cause the CRM project to die a quiet, 
gradual death. 


Solution #10 


The way to avoid long-term difficulties is to treat CRM as a retail 
business with many customer segments. You should keep in mind that 
you may have several hundred or thousand users of this centralized 
system and they may be geographically scattered. CRM must be 
included as a major item in your business strategy. This may be 
accomplished by several stratagems. 


First, measure customer satisfaction. We are talking about two types 
of customer, internal as well as external. Internal customers are your 
employees who deal with employees. Initially measure the satisfaction 
of internal customers and then expand to the external. 


Customer satisfaction surveys should be started within a few weeks of 
putting the CRM project into production status and should then be 
carried out on a regular basis. A carefully constructed questionnaire 
will not only cover results, such as " are you getting the information 
you need" but also probe into potential problem areas, such as 
usability of data, ease of access, ease of use of end-user tools or the 
Web site. The survey should also be accompanied by visits with 
customers. Breadth and depth of customer satisfaction measurements 
will assure continuous improvement of the CRM project on a regular 
basis. 


Establish a policy of continuous promotion of the CRM project, along 
with a mechanism to carry this out. A newsletter, for instance, will 
apprise customers of additions and changes. And while it is doing this, 
it will help shape the image of the CRM project as something 
significant. Speaking at departmental meetings staff meetings and 
publishing productivity-improvement testimonials about the CRM 
project are also useful measures. 


Establish a routine education program. Education does not stop with 
the initial introduction of the CRM project. On the contrary, 
“continuing CRM education" is a major means of keeping the CRM 
project in the center of the business focus. Education should also not 
be restricted to concepts and general information. New directions and 
new tool education should be kept in the forefront, and CRM 
education should offer help in problem solving to increase the 
sophistication level of customers. 


Offer one-on-one consulting. In working with higher- level managers, 
this may be the only means of training in query creation, end- user 
tools and similar facets of the facility. However, making house calls 
will generate favorable publicity and also provide a feedback 
mechanism from the customer community. 


Establish a help desk hot line. A repository and good meta data will 
help, but CRM is new and everyone has a learning curve. In addition, 
new hardware and software requires its own longer learning curve. A 
separate help desk hot line, especially in the beginning, will help 
customers get over many of the teething problems that accompany 
the birth of a new approach. 


Create a CRM user group. The more input the CRM project has and 
the more feedback, the better. Since it requires different type of 
publicity and a forum for use, the CRM user group can maintain 
communication and contribute heavily to the development and 
acceptance of policies, procedures and standards for improved 
business operations. This is a democratic way of developing and 
enforcing your standards and practices for CRM. 


Establish a change monitoring function. Involve the CRM users group 
in changes that affect all systems-related activities. This will require 
creating new administrative loops in such a way that the CRM project 
has advance notice of major changes, even if they are being planned. 
The bigger CRM becomes, the more the CRM users group must be 
involved in technology and systems planning to anticipate the impact 
of changes. In conjunction with this, establish a coordinating 
mechanism with planned new development. 


Each of these activities is important in its own right. Taken as a 
whole, however, they will put the CRM project into the business 
mainstream and keep it there, so that it responds to and changes 
along with customer needs. 


Conclusion 


This article has outlined a number of potential problems and pitfalls 
that could be encountered by those setting out to create a CRM 
project application. Because of varying degrees of experience and 
expertise, no one organization will necessarily encounter all of them. 
The solutions offered, in almost all cases rely on tried-and-true 
common sense principles. By sticking to them, it will not only be 
possible to avoid many of the potholes along the way and complete the 
journey, but also to attain the highest degree of customer satisfaction. 


